1. Field of the Invention
The present invention relates to the exchange of information among service applications in a telecommunications network.
2. Description of the Related Art
One new service application offered by the telecommunications world is the so-called “presence” technology. Presence is a type of application that makes possible to locate and identify a terminal device, herein called a User Equipment (UE), including, for example, handheld computers, Personal Digital Assistants (PDAs), laptops or personal computers (PCs), mobile phones, etc, wherever they might be, as soon as the user connects to the network. One application of presence technology, Instant Messaging (IM), is already very popular. Presence technology is expected to be an integral part of third generation (3G) wireless networks, and is likely to be employed across a wide variety of communication devices, as mentioned. A significant number of wireless application service providers are developing platforms for mobile presence applications.
Presence is also, and mainly, a way for a user to express his willingness to communicate with other users, and to publicize in the network the communication means that he may employ. Among other possibilities, users of the technology may automatically set up an impromptu teleconference by connecting all the parties as soon as they are detected to be available, or present. Privacy issues can be addressed by allowing a high degree of user-defined control, for example by allowing people to select conditions in which they would be seen as present, i.e. detectable.
However, presence technology is not really new. The “finger” service and protocol have been around since the mid-1970s. It was a way to tell who was on a given host and what program they were executing. But for security reasons, nearly everyone has disabled this service and blocked its ports. Today, presence is most often found in the Instant Messaging world, where services such as AOL's AIM™, Microsoft's Messenger™ and Lotus' Sametime™ give friends, family and colleagues the ability to know whether someone is at their computer in addition to the quick text messaging. Predictably, a significant percentage of companies have blocked these services as well.
What is relatively new is the interest in merging instant messaging, IP-based Telephony, and the presence technology. The Internet Engineering Task Force (IETF) and the Third Generation Partnership Project (3GPP) have a number of drafts and specifications in the work, including the Common Presence and Instant Messaging (CPIM) and SIMPLE, which is the SIP (Session Initiation Protocol) for Instant Messaging and Presence Leveraging Extensions. These drafts and specifications define presence-related features and associated signaling protocols allowing network operators to provide presence services to their subscribers. They usually make use of a network entity called a presence server that receives and composes presence information about a user (or even a group of users or a service), which is also called, in the context of a presence-related application, a presence entity. The present server further provides presence information to watcher entities, also called herein watchers, interested in the presence information relating to a presence entity. Watchers can either fetch or monitor the presence information.
Presence information can originate from the network, e.g. from a registration status, activity, or location, or from a number of presence user agents publishing information on behalf of the user, e.g. mobile and fixed devices, application servers, etc.
The presence information associated with an UE may be distributed in the network as an XML document comprising one or more tuples. Reference is now made to FIG. 1 (Prior Art), which depicts an exemplary illustration of such a presence XML document 100 with two tuples 102 and 104. A tuple 102 comprises a tuple identifier 105 for identifying the tupple, and status information 106 related to the presence entity UE, such as for example OPENED or CLOSED status, wherein the status information defines the current status of the communication means described by the tuple. The tuple 102 further comprises other communication means information 108, such as for example short message service (SMS), that defines through which communication means the UE 10 can communicate, and contact address information 110 identifying the UE. Finally, the tuple 102 may comprise one or more attributes 112 that may define various parameters associated with the UE, including data files or links to files. The watcher interested in the presence information of the UE 10 may filter information it is interested in. For example, in a particular SMS broadcast application, a watcher may request from a presence server only UEs' identities which i) tuples' communication means are set to SMS, or ii) tuples' contact addresses are set to a specific value, or are of a specific type (e.g. SIP URI).
Reference is now made to FIG. 2 (Prior Art) that shows an exemplary nodal operation and signal flow diagram of a network 200 implementing an exchange of presence information. Shown in FIG. 2 is a presence server 202 that manages presence information for one or more UEs and a watcher 200 that is interested in presence related information about a given UE from the one or more UEs. First, the presence server 202 receives via the IP Multimedia Subsystem Core Network (IMS, IP multimedia network (IPMM) based on the SIP protocol, such as the one specified by 3GPP) network 211 a SIP PUBLISH message 210 with a presence XML document 212 that comprises one or more tuples with presence information about a given UE (not shown). The PUBLISH message 210 may come from several different sources publishing presence information on behalf of the user, including from the user terminal itself, form a registration action of the user terminal or from other entities of the network. In action 214, the presence server 202 registers the tuples comprised in the XML file 212. In action 216, the watcher 204 sends a SUBSCRIBE message addressed to one of the public contact addresses 218 of the user in the IMS (a SIP URI), and a filter 220. The filter 220 may be in the form of another XML document and may contain any filtering information provided by the watcher 204, defining the presence information it is interested in receiving from the presence server. In action 222, the present server 202 authenticates the message 216. The presence server may need to perform authentication by itself, using standard IETF mechanisms (e.g. HTTP digest), then it applies authorization policies to the request (is the watcher allowed to see presence information?), which may lead to its rejection. Finally, the presence server checks the access rights associated to the watcher, and filters its presence information based on the access rights of the watcher and the filter 220. The presence server 202 returns to the watcher 202 a NOTIFY message with the XML file 212, which is in the present situation contains the result of the filtering 222, action 224. The tuples provided are the intersection between the tuples identified by the filters and those the watcher is allowed to access.
So far, in the existing presence applications, the exchange of presence information is limited to exchanging presence information associated with contact addresses and communication means of UEs. Very recently, a committee of the 3GPP has discussed the possibility of including an application identifier in the text attributes field 112 of a tuple 102, as shown in FIG. 1 (Prior Art). However, no mention was made on the purpose of such inclusion, nor was it mentioned what advantages can be obtained.
The present invention proposes to use an application identifier stored in presence tuples for enabling the exchange of information and commands between applications or components of distributed applications running in terminals (e.g. UEs) and application servers. The exchanges may take place between terminals, between application servers, and between terminals and application servers.